In article <1992Apr28.201638.26520@mintaka.lcs.mit.edu>, rsfinn@concerto.lcs.mit.edu (Russell S. Finn) writes:
|> (Text from original posts deleted...)
|>
|> At first, I was totally confused by this, but the reference to
|> recompiling ANSI suggests to me that you were probably trying to use
|> the supplied ANSI library, which uses 2-byte ints, with code that uses
|> 4-byte ints, and that when you recompiled ANSI, you set the 4-byte int
|> option on -- which is exactly what the manual tells you to do in this
|> case. I suspect that the compiler options you mention actually have
|> little to do with this (in fact, if you look at the ANSI source code,
|> you'll find it takes great pains to work correctly no matter what the
|> 68881 settings are).
|>
|> -- Russell S. Finn
|> rsfinn@lcs.mit.edu
|>
The anecdotes about re-compiling ANSI came from when I had just upgraded
from THINKC 4.x to THINKC 5.x. In 4.x, different ANSI libs were supplied,
while 5.x supplies only one. The 4.x project compiled, but showed the strange
behavior discussed (which sounded like alot of other THINKC 5.x problems
with ANSI functions that have been discussed on the net over the last few
weeks, and e-mail relating to this post).
The original thread is that with the indicated compiler options (specifically
4 byte ints, 68881, 8 byte doubles, native mode FP, 68020) the member
function (used in the bowels of TCL) goes into an infinite loop *EVEN AFTER* ANSI, OOPSDebug (contains member) were re-compiled. Program only works when
"unacceptable" (read no 68881) compile options are used. Also, "infinite loop" should probably be taken with a grain of salt. I suspect it is really in a
for loop to O(2**31), but don't really have the patience to let the program prove this. I suspect that this is a "int which should be short" problem in
TCL or some of the OOP RT support functions (e.g. member). Why it only shows
up in one of my projects (which is very similar to others - read identical
at the OOP level) is mysterious.
Mike Webb
+++++++++++++++++++++++++++
From: phils@chaos.cs.brandeis.edu (Phil Shapiro)
Date: 2 May 92 04:16:22 GMT
Organization: Symantec Corp.
In article <1992Apr28.160517.6873@mailhost.bl.cad.slb.com> mikewebb@boston.sinet.slb.com (Mike Webb) writes:
In addition, various people in comp.sys.mac.programmer have
reported problems with malloc.
This is true, but none of these problems has been due to a bug in
malloc(). The code for malloc() hasn't been changed in 3 years, since
it was shipped with THINK C 4.0. I expect that all of the programmer
groups on Usenet see a lot of traffic regarding problems with dynamic
allocation (except the LISP ones, of course :-).
For Mac purposes, I essentially don't use malloc because of
relocation problems when calls are made across segments (remember,
ANSI is c.28k bytes and usually gets stuck into its own segment!).
It sounds like you're confusing Mac segments with DOS segment
pointers. There isn't any problem with sharing malloc'd pointers
across Mac CODE segments.
The problem that you ran into originally is, I believe, caused by a
bug in the header file oops.h. When you compile with the 4-byte ints
option on, the Class ID parameter to member() is a short int. However,
member uses a varargs prototype, so this argument is widened to a
4-byte int. This can be fixed by modifying the oops.h header file by
replacing the line:
char __member(...);
with the lines:
#if !__option(int_4)
char __member(...);
#else
char __member(void *, short);
#endif
This is not an official fix, but it should work correctly.
